1. Field of the Invention
The present invention relates to transport of Internet Protocol (IP) packets, requiring a guaranteed quality of service (QoS), via secure IP connections.
2. Description of the Related Art
The development of newer protocols for Internet Protocol (IP) networks has extended the capabilities of IP networks. For example, deployment of QoS policies in IP networks has enabled the reliable transport of time-sensitive media data, including audio, video, Voice over IP (VoIP), etc., based on prioritizing the transport of data packets.
In particular, data packets identified as associated with latency-sensitive data traffic (e.g., audio, video, VoIP, etc.) are assigned a higher priority than other lower-priority data packets associated with, for example, Simple Mail Transfer Protocol (SMTP) or User Datagram Protocol (UDP) applications. Hence, an outbound interface in a router may include a high-priority queue (for high priority packets) and a low-priority queue (for low priority packets), enabling the packets to be output by the outbound interface according to their priority and determined capacity: if a network interface driver (i.e., an executable software resource configured for controlling the outbound interface) detects backpressure (i.e., congestion), the network interface driver will reorder outbound traffic based on priority of the data packets (e.g., by avoiding outputting packets from the low-priority queue until the high-priority queue has been emptied). Hence many QoS techniques will reorder packets, causing packets to be output in a sequence that differs from the order the packets were supplied to the outbound interface.
Problems also exist in maintaining a guaranteed quality of service in cases were a destination host is limited in its downstream capacity. For example, a broadband service provider may limit the downstream bandwidth available to a broadband subscriber; hence, even though a headend router is capable of outputting multiple 1024 kbps or higher (e.g., 1.5 Mb/s) media streams on a high-speed interface (e.g., T1 or higher), the destination router within the broadband network may be configured by the broadband service provider to limit the downstream bandwidth to a contracted rate of 1024 kbps.
Consequently, the destination router may drop downstream packets destined for the broadband subscriber if the amount of data traffic exceeds the contracted rate (e.g., 1024 kbps), for example in the case of a destination router receiving, for the broadband subscriber, a 1024 kbps media stream plus a burst of of SMTP packets. The result is reduced network efficiency due to the unnecessary waste of network resources utilized in generation, routing, and transmission of the data packets that ultimately were dropped by the destination router.
The development of secure IP connections involves IP packets passing through encrypted tunnels. In particular, secure IP tunnels have been used to establish virtual private networks (VPNs) between a local area network (e.g., a corporate LAN) and a remote node (e.g., a telecommuter's computer). In particular, a secure IP tunnel is established between the remote node (referred to as the VPN client) and a VPN server that separates the local area network via the wide area network.
The Internet Engineering Task Force (IETF) has published a Request for Comments (2401), by Kent et al., entitled “Security Architecture for the Internet Protocol” available on the IETF website at http://www.ietf.org/rfc/rfc2401.txt?number=2401, the disclosure of which is incorporated in its entirety herein by reference. The above-incorporated RFC 2401 discloses an architecture (referred to as IPSEC) for providing security services for IPv4 or IPv6 data packets at the IP layer, and uses a prescribed Authentication Header (AH) protocol and a prescribed Encapsulating Security Payload (ESP) protocol to provide traffic security. Both the AH protocol and the ESP protocol permit use of anti-replay services (i.e., replay protection), where sequence numbers are added by a transmitting node (e.g., a VPN server) to IP packets being output as a data stream onto an encrypted tunnel.
According to RFC 2401, when a security association (SA) is established between a sender and a receiver, their respective counters (Sequence Counter in the sender and Anti-Replay Window in the receiver) are set to zero: the first packet sent by the sender has a sequence number of “1”, the second packet sent by the sender has a sequence number of “2”, etc., such that each successive packet output by the sender onto that SA has a corresponding successive sequence number.
Hence, the receiver can expect the received data packets to have a respective contiguous sequence of sequence numbers. If the receiver detects a packet having a sequence number that is out of order relative to a previously received packet, the receiver determines the detected packet is an invalid packet and can discard the packet.
The receiver configured for implementing replay protection according to RFC 2401 also will drop packets that are received out-of-order: if the receiver has received packets according to the sequence numbers “1, 2, 3, 4, 100, 101, 5”, the receiver will drop the packet having the sequence number “5”, since it is out of order relative to the packets having the sequence numbers “100” and “101”.
As described above, many QoS techniques reorder packets. The IPSEC architecture, in contrast, requires packets to be received in order of the specified sequence numbers to ensure replay protection. Consequently, the inherent inconsistency between QoS techniques and the IPSEC architecture has caused unnecessary packet loss during past attempts at implementing IPSEC protocol and QoS policies on the same router interface.
In particular, attempts have been made to add IPSEC functionality to QoS-enabled routers in order to provide latency sensitive traffic (including voice and video) over Virtual Private Networks (VPN). Hence, voice and data packets must pass through encrypted tunnels. To date the voice and data packets have encountered IPSEC encryption and sequence number assignment prior to being passed to the outbound driver that performs the QoS functionality. Hence, any detection of congestion by the outbound driver causes reordering of packets such that the higher priority packets are at the front of the outbound queue.
Consequently, the decrypting peer, having detected an IPSEC sequence number that is out of order, drops the packets that were received out of order, even though the dropped packet is a valid, secure packet.
Although some encryption devices utilize queues before input to an encryption chip (i.e., integrated circuit), such queues have been used solely to prevent loss of data due to exceeding the input bandwidth of the encryption chip.